[SOLVED] after # slackpkg upgrade-all upgrades kernel, making a new initramfs is necessary, but not automatic, right?

breaker · 03-20-2022, 01:16 AM

On Slackware 15.0 x64

Code:

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all

After the 'slackpkg upgrade-all' I did get this warning, which was nice:

Code:

Your kernel image was updated, and lilo does not appear to be used on 
your system.  You may need to adjust your boot manager (like GRUB) to 
boot the appropriate kernel (after generating an initrd if required).
Press the "Enter" key to continue...

It updated my kernel from 5.15.19 to 5.15.27 but I use ELILO and the EFI System Partition isn't in the fstab nor mounted automatically, and so ELILO was using the wrong kernel next boot.

But, I couldn't mount the ESP at that moment after the upgrade:

Code:

bash-5.1# mount -t vfat /dev/sdb2 /boot/efi
mount: /boot/efi: unknown filesystem type 'vfat'

I had to use a USB pen drive with GRUB to boot the new kernel in /boot because in the ESP, it had the old. Then I used /usr/share/mkinitrd/mkinitrd_command_generator.sh to suggest a mkinitrd command line, which I used to build a new initrd.gz, mounted the ESP under /boot/efi, and copied the new initrd.gz over the old one in the ESP, and copied the new vmlinuz-generic-5.15.27 to the ESP renaming it to vmlinuz since that is what the elilo.conf is using for the name.

Is this pretty much the routine, or is there a way to automate this? I guess before I run slackpkg upgrade-all next time, I could have a script ready to do everything, like mount the ESP under /boot/efi, make the initrd.gz, and copy the files.

I'm using LVM and the filesystems are ext4.

I guess, in a way this is really a limitation of UEFI only being able to use FAT32, etc. filesystems. Stupid UEFI, lol.

mrmazda · 03-20-2022, 03:05 AM

Sounds like a limitation of not keeping kernels and initrds in a native filesystem, either on the root filesystem in the /boot directory, or on a native filesystem mounted to /boot/. Most distros mount the ESP on /boot/efi/, and put no kernels there. My Slackware kernels are also in the root filesystem in /boot/.

Had the ESP been mounted when the initrd was generated, I would expect vfat support would have been included in the new initrd.

GazL · 03-20-2022, 03:35 AM

Yes, that caught me out once. After you upgrade the kernel-modules package the FAT filesystem driver is no longer present, so if you've not already loaded it into the kernel you will no longer be able to access FAT partitions.

Workaround is to make sure you mount your efi partition before you run upgrade against a kernel-modules packages.

The other, safer, option is to always update your kernel packages with installpkg rather than upgradepkg/upgrade-all, and then removepkg the old ones after you've booted into the new kernel. This is why some folks prefer to blacklist the kernel packages in slackpkg and handle them manually.

Didier Spaier · 03-20-2022, 05:20 AM

Quote:

Originally Posted by breaker

I guess, in a way this is really a limitation of UEFI only being able to use FAT32, etc. filesystems. Stupid UEFI, lol.

Quite the opposite, this was a very wise decision from the writers of the specification. This allows the developers of EFI applications, including but not limited to OS loaders, to follow only one well known specification to write their code, thus drastically reducing the amount of work to do.

Chuck56 · 03-20-2022, 10:36 AM

Quote:

Originally Posted by GazL

The other, safer, option is to always update your kernel packages with installpkg rather than upgradepkg/upgrade-all, and then removepkg the old ones after you've booted into the new kernel. This is why some folks prefer to blacklist the kernel packages in slackpkg and handle them manually.

To quote the Mandalorian: “This Is The Way”

I install multiple kernels & change the kernel naming convention used by Slackware in the ESP.

For new kernels I use installpkg along with blacklisting kernel-generic, huge, modules & source in slackpkg. To generate the new initrd file I use /etc/mkinitrd.conf with: "KRNL="5.16.16" mkinitrd -F -k $KRNL -o /boot/initrd-$KRNL.gz"

Next mount the ESP & copy the newly installed kernel files to the ESP. Finish by modifying elilo.conf for the new kernels.

If you want to keep 2 kernel versions, remove the kernel versions older than those 2 & the associated ESP files & reboot.

Here's my /boot/efi/EFI/Slackware/elilo.conf:

Code:

prompt
timeout=50
default=Gen5.16.16
image=vmlinuz-generic-5.16.15
  label=Gen5.16.15
  initrd=initrd-5.16.15.gz
  append="root=/dev/sda2 resume=/dev/sda1"
  read-only
image=vmlinuz-generic-5.16.16
  label=Gen5.16.16
  initrd=initrd-5.16.16.gz
  append="root=/dev/sda2 resume=/dev/sda1"
  read-only

Here's my /etc/mkinitrd.conf:

Code:

SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
KEYMAP="us"
MODULE_LIST="ext4"
ROOTDEV="/dev/sda2"
ROOTFS="ext4"
UDEV="1"
WAIT="1"
MODCONF="1"

Here's my /etc/fstab ESP entry with the "noauto" option. Mounting the ESP with "mount /boot/efi":

Code:

UUID=1234-5678   /boot/efi         vfat        defaults,noauto         1   0

This process is all scripted.

breaker · 03-20-2022, 01:46 PM

Thanks to all of you friendly and helpful gurus on LinuxQuestions.org!

@mrmazda

Others may correct me if I'm wrong, but I think with ELILO the kernel needs to be in the ESP (EFI System Partition) for booting, and not in the /boot directory. This morning I tried adding another image stanza to my elilo.conf, but it couldn't boot it at all:

Code:

image=/dev/ace0/boot/vmlinuz
        label=vmlinuz
        initrd=/dev/ace0/boot/initrd.gz
        read-only
        root=/dev/ace0/root
        append=""

While the working stanza is:

Code:

image=vmlinuz
        label=efi
        initrd=initrd.gz
        read-only
        root=/dev/ace0/root

The page here seems to confirm this in the section UEFI and ELILO.
Unless it is because I'm using LVM? The LVM and Slackware are on /dev/sda while Windows Server and the ESP live on /dev/sdb, and I use F12 at boot to pick Windows on occasion.

Code:

root@ace:~# lsblk -f
NAME        FSTYPE      FSVER    LABEL    UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda         LVM2_member LVM2 001          dqCChJ-I02s-r3hR-IXBh-o4ye-LrVb-cfw7S7                
├─ace0-swap swap        1                 dd90506d-3f21-42e6-b4d0-30ed3b81197a                  [SWAP]
├─ace0-boot ext4        1.0      boot     b19b2345-03f7-4602-bff7-165f8567eade    117.7M    41% /boot
├─ace0-root ext4        1.0      root     6d9a1c9b-3407-4276-914d-fcca0422f9ab        3G    80% /
├─ace0-home ext4        1.0      home     8ba0252a-ba70-4f75-9fdf-a31378ea6fba     44.5G     4% /home
└─ace0-temp ext4        1.0      temp     47c054f1-66c1-4ed7-9ced-bde3dd734ccc                  
sdb                                                                                             
├─sdb1      ntfs                 Recovery A01EBA041EB9D40E                                      
├─sdb2      vfat        FAT32    EFI      1ABA-2C7F                                51.4M    46% /boot/efi
├─sdb3                                                                                          
└─sdb4      ntfs                          F21ABC211ABBE0B1                                      
sr0                                                                             

root@ace:~# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

@GazL

Got it, I can mount the ESP before upgrade, or blacklist and use installpkg. I think I will do the later.

@Didier Spaier

That's true, and also the FAT specification was released by Microsoft to the public.

@Chuck56

Thanks so much for your detailed real world config file examples.
I would be inclined to use /etc/mkinitrd.conf but I have not yet read all about that script yet, as I should. I shall do so, but the '/usr/share/mkinitrd/mkinitrd_command_generator.sh' worked for me. Here is the output:

Code:

mkinitrd -c -k 5.15.27 -f ext4 -r /dev/ace0/root -m jbd2:mbcache:crc32c_intel:crc32c_generic:ext4 -L -u -o /boot/initrd.gz

I do really appreciate the scripts provided by the Slackware team! But also I do want to learn to edit my own mkinitrd.conf. The '/usr/share/mkinitrd/mkinitrd_command_generator.sh' says it takes into account LVM, which is nice:

Code:

root@ace:~# head -n 35 /usr/share/mkinitrd/mkinitrd_command_generator.sh
#!/bin/sh
# $Id: mkinitrd_command_generator.sh,v 1.45 2011/02/17 09:27:05 eha Exp eha $
# Copyright 2013  Patrick J. Volkerding, Sebeka, Minnesota, USA
# Copyright 2008, 2009, 2010, 2011  Eric Hameleers, Eindhoven, Netherlands
#                                   Contact: <alien@slackware.com>
# Copyright 2008, 2009  PiterPUNK, Sao Paulo, SP, Brazil
#                       Contact: <piterpunk@slackware.com>
# All rights reserved.
#
#   Permission to use, copy, modify, and distribute this software for
#   any purpose with or without fee is hereby granted, provided that
#   the above copyright notice and this permission notice appear in all
#   copies.
#
#   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
#   WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#   MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
#   IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
#   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
#   USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
#   ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
#   OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
#   OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
#   SUCH DAMAGE.
# -----------------------------------------------------------------------------
#
# Create an initrd which fits the system.
# Take into account the use of LVM/LUKS/RAID.
# Find out about any hardware drivers the system may need in an initrd when
# booting from a generic lightweight kernel.
#
# -----------------------------------------------------------------------------

Output is the same whether or not I had the ESP mounted when running it.

Is there anything else to add to the mkintrd.conf for LVM?

Great, Chuck56 that you have it scripted! Do you run it as a cron job so you don't have to do anything at all manually?

I would say my question is "solved" but additional comments are always welcome.

Thanks again to all.

Chuck56 · 03-20-2022, 01:55 PM

Quote:

Originally Posted by breaker

I would be inclined to use /etc/mkinitrd.conf but I have not yet read all about that script yet, as I should. I shall do so, but the '/usr/share/mkinitrd/mkinitrd_command_generator.sh' worked for me.

To create your 1st /etc/mkinitrd.conf file try:

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -c > /etc/mkinitrd.conf

It's kinda the best of both scripts, use one to feed the other.

breaker · 03-20-2022, 02:07 PM

Quote:

Originally Posted by Chuck56

To create your 1st /etc/mkinitrd.conf file try:

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -c > /etc/mkinitrd.conf

It's kinda the best of both scripts, use one to feed the other.

Ah, nice one, thanks!